Dependability Co-Design

It is widely agreed that high levels of software system dependability can only be achieved if the system is designed with dependability in mind; security and other dependability properties cannot be “added-on” to an undependable implementation. However, most modern software development methodologies are based on the notion that quality is achieved through incremental improvement. The question then arises: Are these modern evolutionary methodologies incompatible with strict dependability requirements? Our answer is that they need not be, provided dependability concerns are addressed in a semi-independent, but closely coupled, fashion we call dependability co-design. 1 Functionality versus Dependability A software system is dependable to the extent that it can justifiably be relied upon to satisfy its requirements. Many system properties contribute to dependability. Security is a representative example: clearly, a system containing serious security flaws – say, one that is easily infected by a “virus” transmitted by email – cannot be depended upon to behave as it should. The vast majority of systems have at least a few strong dependability requirements (e.g., that the privacy of passwords must be protected), and some systems have a wide range of extremely stringent dependability requirements. Dependabilty properties tend to be properties of the system as a whole, in the sense that a serious flaw in any part of the system can destroy dependability. For that reason, dependability typically cannot be achieved by adding software to an undependable system. Again, security is a representative example. If a single system component allows unauthorized access to information that must be kept private, the system as a whole is insecure. Plugging the information leak generally requires modification of the component’s internals, and perhaps a change in the system architecture, rather than adding an additional “plug” component. Even worse, leaks can be an emergent property of the system, in the sense that no individual component compromises information security, but the combination of components does so. Thus, the discovery of dependability problems can indicate that extensive — hence, costly — global changes in the system are needed. As a result, there is considerable incentive to make sure that required levels of dependability are designed-in as a system is developed. This observation appears to conflict with recent work on software development methodologies, however. Modern methodologies, from the prototyping-based methodologies of the 1980’s [1] to today’s “eXtreme programming” [2] movement, de-emphasize requirements specification. Rather than trying to specify requirements — a notoriously difficult business with typically unsatisfactory results — one proceeds with programming based on an informal understanding of what the system is supposed to do. Once an executable program is available, the customer can evaluate whether it satisfies his (still unstated) requirements. If not, he can request that specific changes be made, still without having to explain exactly how those changes contribute to requirements satisfaction, much less what the requirements are. The common feature of these methodologies is the emphasis on evolution as the means of achieving requirements satisfaction. There are two sorts of arguments in favor these modern evolutionary methodologies, one positive and the other negative. The positive argument is that, historically, virtually all systems that are now considered to be high-quality have evolved from earlier versions that were lower quality in response to market demands. The negative argument is that, historically, customers have been unable to fully explicate their requirements. Almost without exception, when development is based on an initial requirements specification and the assumption that any system that satisfies the specified requirements will be acceptable, the customer winds up disappointed by the final product. So the modern development methodologies amount to nothing more than codifications of what experience has shown to work best. Does adoption of a development methodology that eschews a great deal of “upfront” formal design doom a developer to either extensive redesign and re-implementation to achieve dependability after the desired functionality has been achieved, or living